WordPress Loginizer Plugin has released a security patch addressing a vulnerability that could permit a hacker to alter a database through an Unauthenticated SQL Injection exploit.
This type of exploit, often referred to as a Blind SQL Injection, involves inputting data to trigger an error response. Here, the input is a username.
The Loginizer WordPress plugin lacked a mechanism to sanitize input, meaning it couldn’t handle erroneous input properly, leading to an error situation.
According to WPScan’s description of the Loginizer exploit:
“The vulnerability was triggered within the brute force protection functionality, which was enabled by default when the plugin was first installed. When a user attempts to log in with an unknown username, the attempt is logged in the backend database, where the username, as well as other parameters, are not properly validated before being placed within the SQL query.”
The security researcher who discovered the vulnerability shared a detailed walkthrough of the Loginizer exploit, demonstrating how an error response can be exploited to access parts of the plugin related to its functionality, thus exposing it to a SQL injection.
The researcher explained it like this:
“…via function definition we see how raw $username reaches the plugin functionality… Also in this function there are calls towards DB with not sanitized DB parameters… and we see the places that are vulnerable of SQLi based on user login data.”
The walkthrough includes a proof of concept and concludes:
“…And that is it, more than easy and detailed about SQLi + XSS via $username.”
Stored XSS Vulnerability
The issues with Loginizer are not limited to the SQL injection vulnerability; there are two problems in total.
The second exploit is called a Stored Cross-Site Scripting (Stored XSS) vulnerability, a particularly severe type of XSS vulnerability.
With this exploit, a hacker can typically inject malicious files directly, exploiting both the WordPress site and its users. Generally, a malicious file can be delivered to the site visitor’s browser.
Loginizer Changelog
A changelog logs all changes made by a software developer to the software. When you update a plugin, WordPress allows you to click and see a description of those changes. These descriptions come from the changelog. All WordPress plugin developers maintain a running changelog in the WordPress plugin repository and often on their website.
According to the official Loginizer changelog, these issues affect versions prior to the latest, which is Loginizer version 1.6.4.
The Loginizer plugin changelog describes the two patches as follows:
“[Security Fix]: A properly crafted username used to log in could lead to SQL injection. This has been fixed by using the prepare function in PHP, which prepares the SQL query for safe execution.
[Security Fix]: If the IP HTTP header was modified to have a null byte, it could lead to stored XSS. This has been fixed by properly sanitizing the IP HTTP header before using the same.”
Loginizer should be commended for being forthright in describing the issue in their changelog.
Screenshot of Loginizer Plugin Changelog
![Screenshot of official Loginizer WordPress plugin changelog]
Some plugin publishers try to obscure that an update is a security fix by using technical jargon and not mentioning the security fix.
Being honest about what the update entails, as Loginizer does, is a sign of a good plugin developer.
WordPress Auto Update
WordPress triggered a forced auto-update. Most sites running this plugin, up to 89%, should have had their plugin successfully updated.
It is highly recommended that all WordPress publishers using the Loginizer security plugin check which version of the plugin they are using and update it immediately if they have not already done so.
